How does the Camel API compare to from CXF, HTTP, JBI, JMS, JavaMail, etc.

We have tried to make the Camel Exchange and Message map very closely to JBI in particular but also CXF, HTTP, JMS, Mail, XMPP and most other integration abstractions. We want to prevent leaky abstractions, so the Camel API exposes the underlying APIs so that a Processor can make use of the underlying abstractions if they make sense.

For example:

Component	Inbound exchange exposes
CXF	Each Inbound CxfExchange has access to the underlying Exchange and Message from CXF
HTTP	Each inbound HttpExchange has access to the underlying HttpServletRequest and HttpServletResponse
JBI	Each inbound JbiExchange has access to the underlying JBI MessageExchange and NormalizedMessage objects
JMS	Each inbound JmsExchange has access to the underlying JMS Message objects

Component

Inbound exchange exposes

CXF

Each Inbound CxfExchange has access to the underlying Exchange and Message from CXF

HTTP

Each inbound HttpExchange has access to the underlying HttpServletRequest and HttpServletResponse

JBI

Each inbound JbiExchange has access to the underlying JBI MessageExchange and NormalizedMessage objects

JMS

Each inbound JmsExchange has access to the underlying JMS Message objects

You can probably see a pattern forming now :smile:

For many routing and mediation components and Processor objects, you maybe don’t care about the underlying transport and can instead stick to the abstract Camel API. But if you need to, the real transport APIs are there for you.