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
<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).
<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
<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.
Working with InOnly method calls
As of 1.5 Camel supports the @InOnly and @Pattern annotations to let you specify which methods are not InOut (Request Reply) but are InOnly (oneway or fire and forget Event Message).
For more details see Using Exchange Pattern Annotations
Bean Binding
The Bean Binding in Camel defines both which methods are invoked and also how the Message is converted into the parameters of the method when it is invoked.
Choosing the method to invoke
The binding of a Camel Message to a bean method call can occur in different ways
- the method name can be specified explicitly in the DSL or when using POJO Consuming
- 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 JMS MessageListener to be invoked directly by Camel without having to write any integration glue code. You can use the same mechanism to integrate Camel into any other messaging/remoting frameworks.
- 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.
Binding Annotations
You can use the Parameter Binding Annotations to customize how parameter values are created from the Message
Examples
For example a Bean such as:
public class Bar {
public String doSomething(String body) {
return "Bye World";
}
Or the Exchange example. Notice that the return type must be void:
public class Bar {
public void doSomething(Exchange exchange) {
exchange.getIn().setBody("Bye World");
}
For example you could use POJO Consuming to write a bean like this
![]() | @MessageDriven requires camel-spring
Using the @MessageDriven annotations requires camel-spring that uses the org.apache.camel.spring.CamelBeanPostProcessor to perform the setup for this consumer and the needed bean bindings. |
public class Foo {
@MessageDriven(uri = "activemq:my.queue")
public void doSomething(String body) {
}
}
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.
