Page Comparison

...

Concept of a DSL

A Domain-Specific Language (DSL) is a mini-language designed for a special purpose. It tends to be a tier on top of an existing object-oriented language (Java, Groovy, etc), and this provides the DSL with the constructs cleanly map to the host language API. A DSL does not have to be logically complete (like Java or Groovy), but needs enough power to describe problems adequately in the chosen domain. Typically, a DSL does not require a dedicated parser, interpreter, or compiler.

Syntax of Router Rule

Apache Camel defines a router DSL for defining routing rules. You can use this DSL to define your rules and the illustration below shows an overview of the basic syntax for defining local routing rules.

...

Local Routing Rules

A local rule always will always start with a from(“EnpointURL”) method, which specifies the source of messages (consumer endpoint) for the routing rule. Then, we can add an arbitrarily long chain of processors to the rule (for example, filter()). You typically finish off the rule with a to(“EndpointURL”) method, which specifies the target (producer endpoint) for all of the messages that are passing through the routing rule.

Consumers and producers

A local rule will always start by defining a consumer endpoint, using the from(“EndpointURL”) method and then generally it will end by identifying a producer endpoint with to(“EndpointURL”). The endpoint URLs, EndpointURL, can use any of the components configured at deployment time.

For example, you could use a file endpoint, file:MyMessageDirectory, an Apache CXF endpoint, cxf:MyServiceName, or an Apache ActiveMQ endpoint, activemq:queue:MyQName.

Exchanges

An exchange object consists of a message and is then augmented by metadata. Exchanges are of central importance in Apache Camel, because the exchange is the standard form in which messages are propagated through routing rules. The main ingredients of an exchange are, as follows:

...

Producer endpoints — the MEP will impact the producer endpoints that our exchange passes through along the route. For example, if the current MEP has been set InOnly, a destination node would not expect to receive a reply from the endpoint. There may be occasions when we need to change the state of the MEP to customize the exchange’s interaction with a producer endpoint.

Message exchange patterns

The use of an Exchange object makes it simple to generalize message processing to different message exchange patterns. As an example, an asynchronous protocol might define an MEP that consists of a single message that travels from the consumer to producer endpoint (ie. InOnly MEP).

...

• InOnly

• RobustInOnly

• InOut

• OutOnly

• InOptionalOut

• OutIn

• OutOptionalIn

• RobutstOutOnly

Processors

A processor is a node in a route that can access and modify the stream of exchanges passing through the route. Processors can accept either expression or predicate arguments that can modify their behavior. As an example, the local routing rule shown earlier on this page includes a Filter processor that takes an XPath() predicate as its passed argument.

Expressions and Predicates

Within our routing rules, we will use; Expressions (evaluating to strings or other data types), and predicates (evaluating to true or false) and these can occur frequently as arguments to the different processor types. For example, the following filter rule propagates input messages, only if the hello header is equal to the value of “helloworld”:

from("account:a"").filter(header("hello").isEqualTo("helloworld").to("acct:b"")