2011-08-31
Cloud integration with Apache Camel
I actually just want to bring the attention of Kai Wähner who posts some great blog entries about Apache Camel. One of his last posts is about Amazon cloud integration with Apache Camel.
2011-08-17
Apache Camel - Bean integration improved
I might as well continue this month with a blog post about a new feature in the upcoming Apache Camel 2.9 release I implemented a couple of weeks ago.
Apache Camel has always had great integration for using beans. You had all kind of options to pick and chose according to your needs and liking.
When Camel invokes a bean, it uses a strategy to adapt to the bean. It introspects the bean and using an algorithm if figures out the method to invoke and how to bind to the parameters of the method signature.
This algorithm is detailed in chapter 4 in the Camel in Action book, figure 4.5 and 4.6.
So what have we added in Camel 2.9? Well one area where the previous logic was a bit lacking was binding to methods with multiple parameters and by which some parameters would have to be instructed using annotations how to bind.
Imagine this method signature
What we would like to do from a Camel route is to invoke this method, with the message payload as the first parameter, and true for the 2nd parameter.
This is now more easy in Camel 2.9 as you can declare the binding directly in the Camel route as shown:
This applies as well when using .to
In fact Camel uses the Simple language in the syntax which allows you to bind message headers, properties, invoke other beans, property placeholder values etc.
In fact you can even invoke methods using the OGNL support from Simple. Now suppose the message body is a Java object which has a method called asXml(), and you would pass the result of this method invocation to the doSomething method. This can simply be done as follows:
You can omit the () and this time for the boolean parameter we bind to a message header with the key high
You can read more details in the parameter binding using method option section in the Apache Camel documentation.
Apache Camel has always had great integration for using beans. You had all kind of options to pick and chose according to your needs and liking.
When Camel invokes a bean, it uses a strategy to adapt to the bean. It introspects the bean and using an algorithm if figures out the method to invoke and how to bind to the parameters of the method signature.
This algorithm is detailed in chapter 4 in the Camel in Action book, figure 4.5 and 4.6.
So what have we added in Camel 2.9? Well one area where the previous logic was a bit lacking was binding to methods with multiple parameters and by which some parameters would have to be instructed using annotations how to bind.
Imagine this method signature
public void doSomething(String payload, boolean highPriority)
What we would like to do from a Camel route is to invoke this method, with the message payload as the first parameter, and true for the 2nd parameter.
This is now more easy in Camel 2.9 as you can declare the binding directly in the Camel route as shown:
.bean(OrderService.class, "doSomething(${body}, true)")This applies as well when using .to
.to("bean:myOrderService?method=doSomething(${body}, true)")In fact Camel uses the Simple language in the syntax which allows you to bind message headers, properties, invoke other beans, property placeholder values etc.
In fact you can even invoke methods using the OGNL support from Simple. Now suppose the message body is a Java object which has a method called asXml(), and you would pass the result of this method invocation to the doSomething method. This can simply be done as follows:
.to("bean:myOrderService?method=doSomething(${body.asXml()}, true)")You can omit the () and this time for the boolean parameter we bind to a message header with the key high
.to("bean:myOrderService?method=doSomething(${body.asXml}, ${header.high}")
You can read more details in the parameter binding using method option section in the Apache Camel documentation.
2011-08-16
Upcoming webinar - Apache Camel - How to go from EIPs to production
Next week I am speaking at a webinar on Apache Camel hosted by FuseSource.
Based on the integration patterns developed by Gregor Hohpe and Bobby Woolf, Apache Camel originated four years ago. James Strachan, technical director and software fellow at FuseSource and co-founder of the project with Rob Davies – now CTO of FuseSource – posted the first commit of the project on March 19, 2007.
In the years since, Apache Camel has emerged as one of the most popular integration frameworks and a singular example of open source technology that gives developers the freedom they need to solve real world business problems cost effectively and quickly – all while benefiting from and contributing to one of the most vibrant and innovative open source communities, the Apache Software Foundation.
“This webinar is merely another reflection of our commitment to help more developers and architects realize the proven superiority and value of Apache Camel,” added Ibsen. “If you don’t use it, you are working harder at application integration than you should.”
The webinar takes place on tuesday August 23rd. You can see more details here and register for the event.
Based on the integration patterns developed by Gregor Hohpe and Bobby Woolf, Apache Camel originated four years ago. James Strachan, technical director and software fellow at FuseSource and co-founder of the project with Rob Davies – now CTO of FuseSource – posted the first commit of the project on March 19, 2007.
In the years since, Apache Camel has emerged as one of the most popular integration frameworks and a singular example of open source technology that gives developers the freedom they need to solve real world business problems cost effectively and quickly – all while benefiting from and contributing to one of the most vibrant and innovative open source communities, the Apache Software Foundation.
“This webinar is merely another reflection of our commitment to help more developers and architects realize the proven superiority and value of Apache Camel,” added Ibsen. “If you don’t use it, you are working harder at application integration than you should.”
The webinar takes place on tuesday August 23rd. You can see more details here and register for the event.
2011-08-13
Two new Fuse IDE videos showing Camel development and runtime message tracing
The Fuse IDE, which is our developer tooling for Apache Camel, ServiceMix and ActiveMQ was recently released as 2.0. This new major versions introduces major new features in the area of insight into running applications. For example you can browse endpoints, JMX trees, view any Camel routes as graphical EIPs, and trace messages.
At FuseSource we have created two videos to show this tooling in Action. The first video shows how you can create a new Camel project that throttles a web service between two business.
The 2nd video shows the Camel insight in action, where you can browse endpoints, send messages to endpoints, and trace messages as they are being routed. That means you can see a graphical representation of the route and step through the route and see the content of the message as it changes.
You can see the videos from the following links
We will create and publish new videos in the future to demonstrate other features of the Fuse IDE tooling. So stay tuned. You can read and see more details about Fuse IDE here. If you have feedback and issues using the tooling you can use our online forum to get in touch with us and talk to other users.
 |
| Browsing endpoints and JMX |
At FuseSource we have created two videos to show this tooling in Action. The first video shows how you can create a new Camel project that throttles a web service between two business.
 |
| Throttling a service between two business |
 |
| Tracing messages in Camel routes (single step) |
You can see the videos from the following links
We will create and publish new videos in the future to demonstrate other features of the Fuse IDE tooling. So stay tuned. You can read and see more details about Fuse IDE here. If you have feedback and issues using the tooling you can use our online forum to get in touch with us and talk to other users.
2011-08-08
Apache Camel 2.9 - Reduced dependency on Spring JARs
One of the goals for Apache Camel 2.9 is to reduce dependency on Spring JARs in both the camel-core and other components.
In the core we used the Spring JMX annotations to more easily export Camel MBeans into JMX. This dependency is an optional dependency on Spring JARs as you would need those in case you want to manage Camel using JMX. Unfortunately Spring does not provide a light weight API for the JMX pieces, and you end up loading in 6+ Spring JARs. This is of course not desirable, so we moved forward a goal for Camel 3.0 to the upcoming Apache Camel 2.9 release, which is to provide a Camel set of JMX annotations and use pure Java JMX logic to enlist those.
This work has been carried out, and you can now use Camel JMX with no Spring JARs at all at runtime.
To be compatible with the Spring JMX annotations, we moved the old logic from camel-core to camel-spring component. So you can still use Spring JMX annotations in your custom Camel components / beans / processors etc. and have them enlisted in JMX, together with the other Camel MBeans.
The camel-core JAR in Camel 2.9 onwards now only depend on the SLF4j logging API. This is as low dependency we want to go.
The dependency tree report by Apache Maven is now simply:
[INFO] org.apache.camel:camel-core:bundle:2.9-SNAPSHOT
[INFO] +- org.slf4j:slf4j-api:jar:1.6.1:compile
A number of Camel components used the Spring IO Resource to load template files from the file system or classpath. This didn't work in OSGi blueprint containers, so we decided to use existing code from camel-core instead. This means a total of 11 components now do not depend on Spring JARs either. We also identified a component in camel-spring, which could be moved to camel-core. For example the XSLT component has now been moved from camel-spring to camel-core.
So what's left? Which components depend on Spring JARs? Well there is only camel-mail and camel-jms left. In the former we only use Spring to send emails, and there is a contribution from the community to use plain Java Mail API to send emails. So it should be a matter of time before camel-mail is migrated as well. The camel-jms component is built on top of spring-jms, especially its MessageListenerContainer abstraction. Therefore it is not feasible to remove Spring dependency. However we may consider creating a new light weight JMS component in the future, having less bells and whistles as the current component, but keeping it simpler and leaner.
So does this mean we dont like Spring? Well of course we do, but Spring is not the center of the universe. Apache Camel is used in a lot of different systems and environments. Its important that Camel can easily fit into your environment. For example if you use JEE then JEE containers offers a lot of the same capabilities as Spring does. Now you can more easily use JEE and Camel without dragging Spring along.
Apache Camel 2.9 will still be as powerful integrated with Spring as it has always been. There is no changes for any existing users who use Spring and Camel together.
In the core we used the Spring JMX annotations to more easily export Camel MBeans into JMX. This dependency is an optional dependency on Spring JARs as you would need those in case you want to manage Camel using JMX. Unfortunately Spring does not provide a light weight API for the JMX pieces, and you end up loading in 6+ Spring JARs. This is of course not desirable, so we moved forward a goal for Camel 3.0 to the upcoming Apache Camel 2.9 release, which is to provide a Camel set of JMX annotations and use pure Java JMX logic to enlist those.
This work has been carried out, and you can now use Camel JMX with no Spring JARs at all at runtime.
To be compatible with the Spring JMX annotations, we moved the old logic from camel-core to camel-spring component. So you can still use Spring JMX annotations in your custom Camel components / beans / processors etc. and have them enlisted in JMX, together with the other Camel MBeans.
The camel-core JAR in Camel 2.9 onwards now only depend on the SLF4j logging API. This is as low dependency we want to go.
The dependency tree report by Apache Maven is now simply:
[INFO] org.apache.camel:camel-core:bundle:2.9-SNAPSHOT
[INFO] +- org.slf4j:slf4j-api:jar:1.6.1:compile
A number of Camel components used the Spring IO Resource to load template files from the file system or classpath. This didn't work in OSGi blueprint containers, so we decided to use existing code from camel-core instead. This means a total of 11 components now do not depend on Spring JARs either. We also identified a component in camel-spring, which could be moved to camel-core. For example the XSLT component has now been moved from camel-spring to camel-core.
So what's left? Which components depend on Spring JARs? Well there is only camel-mail and camel-jms left. In the former we only use Spring to send emails, and there is a contribution from the community to use plain Java Mail API to send emails. So it should be a matter of time before camel-mail is migrated as well. The camel-jms component is built on top of spring-jms, especially its MessageListenerContainer abstraction. Therefore it is not feasible to remove Spring dependency. However we may consider creating a new light weight JMS component in the future, having less bells and whistles as the current component, but keeping it simpler and leaner.
So does this mean we dont like Spring? Well of course we do, but Spring is not the center of the universe. Apache Camel is used in a lot of different systems and environments. Its important that Camel can easily fit into your environment. For example if you use JEE then JEE containers offers a lot of the same capabilities as Spring does. Now you can more easily use JEE and Camel without dragging Spring along.
Apache Camel 2.9 will still be as powerful integrated with Spring as it has always been. There is no changes for any existing users who use Spring and Camel together.
Subscribe to:
Posts (Atom)
