-
Notifications
You must be signed in to change notification settings - Fork 0
Camel
- Blog discussing the use of aggregator
- Comparison to Spring Integration
Two abstractions:
- Message (
org.apache.camel.Message) - Exchange ('org.apache.camel.Exchange')
Three parts:
- Headers
- Attachments
- Body
During routing, messages are contained in an exchange
An exchange in Camel is the message's container during routing. An exchange also provides support for the various types of interactions between systems, aka message exchange patterns (MEPs). MEPs are used to differentiate between one-way and request-response messaging styles.
-
InOnly- a one-way message (aka anEventmessage) -
InOut- a request-response message
A Camel exchange has:
- ID (exchange ID)
- MEP
- Exception
- Properties - similar to message headers, but they last for the duration of the entire exchange. (read up a bit more)
- In message - input message, the in message contains the request message
- Out message - optional message that only exists if the MEP is
InOut. The out message contains the reply message
Camel is composed of:
- processors
- components
- routes
All these are contained within the CamelContext
One of the services that CamelContext provides is Registry which allows you to look up beans. Default will be a JNDI registry but using Camel from Spring, this will be the Spring ApplicationContext.
Can the registry be based on Guice?
Each route in Camel has a unique identifier (used for logging, debugging, monitoring and starting and stopping routes). Routes have exactly one input source for messages, effectively tied to an input endpoint.
Handle things in between endpoints like
- EIPs
- Routing
- Transformation
- Mediation
- Enrichment
- Validation
- Interception
Associated with a name that's used in a URI and they act as a factory of endpoints.
E.g. a FileComponent is referred to by file in a URI, and it creates FileEndpoints.
An endpoint is the Camel abstraction that models the end of a channel through which a system can send or receive messages.
In Camel, you configure endpoints using URIs, such as file:data/inbox?delay=5000, and also refer to endpoints the same way.
Endpoint URIs are divided into three parts:
file:data/inbox?delay=5000
[1]:[2 ]?[3 ]
scheme : context path ? options
Endpoint acts as a factory for creating consumers and producers that are capable of receiving and sending mesages to a particular endpoint.
A producer is the Camel abstraction that refers to an entity capable of creating and sending a message to an endpoint.
When a message needs to be sent to an endpoint, the producer will create an exchange and populate it with data compatible with that particular endpoint. E.g. a FileProducer will write the message body to a file. A JmsProducer, will map the Camel message to a javax.jms.Message before sending it to a JMS destination.
A consumer is the service that receives messages produced by a producer, wraps them in an exchange and sends them to be processed. Consumers are the source of the exchanges being routed in Camel.
Two types of consumers:
- Event-driven
- Polling
Asynchronous receiver in the EIP world.
E.g. TCP/IP port, JMS queue
Synchronous receiver in EIP.
E.g. FTP server (?), File, email transports all use scheduled polling consumers.
In JMS, message consumers and producers talk to one another through an intermediary - JMS destination. A destination can be either a queue or a topic.
Queues are point-to-point, where each message has only one consumer. Topics operate on a publish/subscribe scheme; a single message may be delivered to many consumers if they have subscribed to the topic.
JMS also provides a ConnectionFactory that clients (like Camel) can use to create a connection with a JMS provider. JMS providers are usually referred to as brokers because they manage the communication between a message producer and a message consumer.