Spring RemotingWe support Spring Remoting 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 RemotingIn your Spring XML just use the CamelProxyFactoryBean Then to implement the service you use CamelServiceExporter The following example <!-- 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 NamespacesIn this example <!-- 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 OptionalNote 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 bindingThe binding of a Camel Message to a bean method call can occur in different ways
You can also use the @Property For example you could write a method like this 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. You could process some headers if you wish like this 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 (again with possible type conversion too). 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"); |