Chapter 4. Using beans with Camel

 

This chapter covers

  • Understanding the Service Activator EIP
  • How Camel looks up beans using registries
  • How Camel selects bean methods to invoke
  • Bean parameter binding with single and multiple parameters

If you’ve been developing software for five years or longer, you’ve likely worked with different component models, such as CORBA, EJB, JBI, SCA, and lately OSGi. Some of these models, especially the earlier ones, imposed a great deal on the programming model, dictating what you could and couldn’t do, and they often required complex packaging and deployment models. This left the everyday engineer with a lot of concepts to learn and master. In some cases, much more time was spent working around the restrictive programming and deployment models than on the business application itself.

Because of this growing complexity and the resulting frustrations, a simpler, more pragmatic programming model arose from the open source community: the POJO model. Later this was formalized as the Spring Framework.

The Spring Framework has opened the door to the enterprise, proving that the POJO programming model and a lightweight container indeed meet the expectations of today’s businesses. In fact, the simple programming model and lightweight container concept proved superior to the heavyweight and over-complex enterprise application and integration servers that were used before.

4.1. Using beans the hard way and the easy way

4.2. The Service Activator pattern

4.3. Camel’s bean registries

4.4. Selecting bean methods

4.5. Bean parameter binding

4.6. Summary and best practices

sitemap