The Camel context is the runtime container where Camel runs it. The Message body can de made of several types of data, such as binaries, JSON, etc. For that type of data, it is better to use Exchange properties. So, Message headers must be seen as ephemeral data, that will not be used through the whole route. One important aspect to keep in mind, however, is that along a Camel route our Messages are changed – when we convert the body with a Type converter, for instance – and when this happens, we lose all our headers. A Message can have a body, which is the data itself and headers, which are, like properties on a Exchange, key-value entries that can be used along the processing. Messages are the data itself that is transferred inside a Camel route. Also, a Exchange can have properties, represented as key-value entries, that can be used as data that will be used across the whole route (we will see more about routes very soon) Message The output message on Camel is optional, since we could have a integration that doesn’t have a response.
A Exchange can have 2 messages inside, one representing the input and another one representing the output of a integration.
Terminology ExchangeĮxchanges – or MEPs(Message Exchange Patterns) – are like frames where we transport our data across the integrations on Camel. The Java Business Integration specification specifies a plug and play platform for systems integrations, following the EIP (Enterprise Integration Patterns) patterns. Apache Service Mix was a project powered by the Spring Framework and implemented following the JBI specification. On this post, we will talk about Apache Camel, a robust solution for deploying system integrations across various technologies, such as REST, WS, JMS, JDBC, AWS Products, LDAP, SMTP, Elasticsearch etc.Īpache Camel was created on Apache Service Mix.
0 kommentar(er)
