This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 9908659 CAMEL-16861: Cleanup and update EIP docs
9908659 is described below
commit 9908659cd9edcf7ff6b5be1642313313f2afee55
Author: Claus Ibsen <[email protected]>
AuthorDate: Tue Oct 12 09:47:24 2021 +0200
CAMEL-16861: Cleanup and update EIP docs
---
.../docs/modules/eips/pages/event-message.adoc | 33 ++++--
.../docs/modules/eips/pages/requestReply-eip.adoc | 118 +++++++++++++++++----
2 files changed, 120 insertions(+), 31 deletions(-)
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc
index 2d69fa0..81218a5 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc
@@ -1,18 +1,26 @@
= Event Message
Camel supports the
-http://www.enterpriseintegrationpatterns.com/EventMessage.html[Event
-Message] from the xref:enterprise-integration-patterns.adoc[EIP
-patterns] by supporting the
xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern]
-on a xref:message.adoc[Message] which can be set to *InOnly* to indicate
-a oneway event message. Camel xref:components::index.adoc[Components] then
-implement this pattern using the underlying transport or protocols.
+http://www.enterpriseintegrationpatterns.com/EventMessage.html[Event Message]
+from the xref:enterprise-integration-patterns.adoc[EIP patterns].
+
+How can messaging be used to transmit events from one application to another?
image::eip/EventMessageSolution.gif[image]
-The default behaviour of many xref:components::index.adoc[Components] is InOnly
+Use an Event Message for reliable, asynchronous event notification between
applications.
+
+Camel supports Event Message by the
xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern]
+on a xref:message.adoc[Message] which can be set to `InOnly` to indicate
+a oneway event message. Camel xref:components::index.adoc[Components] then
+implement this pattern using the underlying transport or protocols.
+
+The default behaviour of many xref:components::index.adoc[Components] is
`InOnly`
such as for xref:components::jms-component.adoc[JMS],
xref:components::jms-component.adoc[File] or
-xref:components::seda-component.adoc[SEDA]
+xref:components::seda-component.adoc[SEDA].
+
+Some components support both `InOnly` and `InOut` and act accordingly. For
example the xref:components::jms-component.adoc[JMS]
+can send messages as one-way (`InOnly`) or use request/reply messaging
(`InOut`).
TIP: See the related xref:requestReply-eip.adoc[Request Reply] message.
@@ -90,3 +98,12 @@ NOTE: Using `setExchangePattern` to change the
xref:latest@manual:ROOT:exchange-
is often only used in special use-cases where you must
force to be using either `InOnly` or `InOut` mode when using components that
support both modes (such as messaging components like ActiveMQ, JMS, RabbitMQ
etc.)
+== JMS component and InOnly vs InOut
+
+When consuming messages from xref:components::jms-component.adoc[JMS] a
Request Reply is
+indicated by the presence of the `JMSReplyTo` header. This means the JMS
component automatic
+detects whether to use `InOnly` or `InOut` in the consumer.
+
+Likewise, the JMS producer will check the current
xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern]
+on the xref:latest@manual:ROOT:exchange.adoc[Exchange] to know whether to use
`InOnly` or `InOut` mode (i.e. one-way vs request/reply messaging)
+
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
index c9f8ad5..4e0646e 100644
---
a/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
+++
b/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc
@@ -1,42 +1,114 @@
= Request Reply
Camel supports the
-http://www.enterpriseintegrationpatterns.com/RequestReply.html[Request
-Reply] from the EIP patterns
-by supporting the Exchange Pattern on a
-Message which can be set to *InOut* to indicate a
-request/reply. Camel Components then implement
-this pattern using the underlying transport or protocols.
+http://www.enterpriseintegrationpatterns.com/RequestReply.html[Request Reply]
+from the xref:enterprise-integration-patterns.adoc[EIP patterns].
+
+When an application sends a message, how can it get a response from the
receiver?
image::eip/RequestReply.gif[image]
-For example when using xref:components::jms-component.adoc[JMS] with InOut the
component will
-by default perform these actions
+Send a pair of Request-Reply messages, each on its own channel.
+
+Camel supports Request Reply by the
xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern]
+on a xref:message.adoc[Message] which can be set to `InOut` to indicate a
+request/reply message. Camel xref:components::index.adoc[Components] then
+implement this pattern using the underlying transport or protocols.
+
+For example when using xref:components::jms-component.adoc[JMS] with `InOut`
the component will
+by default perform these actions:
* create by default a temporary inbound queue
-* set the JMSReplyTo destination on the request message
-* set the JMSCorrelationID on the request message
+* set the `JMSReplyTo` destination on the request message
+* set the `JMSCorrelationID` on the request message
* send the request message
-* consume the response and associate the inbound message to the request
-using the JMSCorrelationID (as you may be performing many concurrent
-request/responses).
+* consume the response and associate the inbound message to the belonging
request
+using the `JMSCorrelationID` (as you may be performing many concurrent
request/responses).
+* continue routing when the reply is received and populated on the
xref:latest@manual:ROOT:exchange.adoc[Exchange]
TIP: See the related xref:eips:event-message.adoc[Event Message].
-[[RequestReply-ExplicitlyspecifyingInOut]]
-== Explicitly specifying InOut
+== Using endpoint URI
+
+If you are using a component which defaults to `InOnly` you can override
+the xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern] for a
*consumer* endpoint using
+the pattern property.
-When consuming messages from xref:components::jms-component.adoc[JMS] a
Request-Reply is
-indicated by the presence of the *JMSReplyTo* header.
+[source,text]
+----
+foo:bar?exchangePattern=InOut
+----
-You can explicitly force an endpoint to be in Request Reply mode by
-setting the exchange pattern on the URI. e.g.
+IMPORTANT: This is only possible on endpoints used by consumers (i.e. in
`<from>`).
-[source]
+In the example below the message will be forced as a request reply message as
the consumer
+is in `InOut` mode.
+
+[source,java]
+----
+from("jms:someQueue?exchangePattern=InOut")
+ .to("bean:processMessage");
----
-jms:MyQueue?exchangePattern=InOut
+
+And with XML:
+
+[source,xml]
+----
+<route>
+ <from uri="jms:someQueue?exchangePattern=InOut"/>
+ <to uri="bean:processMessage"/>
+</route>
+----
+
+== Using setExchangePattern EIP
+
+You can specify the
+xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern] using
`setExchangePattern` in the DSL.
+
+[source,java]
----
+from("direct:foo")
+ .setExchangePattern(ExchangePattern.InOut)
+ .to("jms:queue:cheese");
+----
+
+And with XML:
+
+[source,xml]
+----
+<route>
+ <from uri="direct:foo"/>
+ <setExchangePattern pattern="InOut"/>
+ <to uri="jms:queue:cheese"/>
+</route>
+----
+
+When using `setExchangePattern` then the
xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern]
+on the xref:latest@manual:ROOT:exchange.adoc[Exchange] is changed from this
point onwards in the route.
+
+This means you can change the pattern back again at a later point:
+
+[source,java]
+----
+from("direct:foo")
+ .setExchangePattern(ExchangePattern.InOnly)
+ .to("jms:queue:one-way");
+ .setExchangePattern(ExchangePattern.InOut)
+ .to("jms:queue:in-and-out")
+ .log("InOut MEP received ${body}")
+----
+
+NOTE: Using `setExchangePattern` to change the
xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern]
+is often only used in special use-cases where you must
+force to be using either `InOnly` or `InOut` mode when using components that
support both modes (such as messaging components like ActiveMQ, JMS, RabbitMQ
etc.)
+
+== JMS component and InOnly vs InOut
+
+When consuming messages from xref:components::jms-component.adoc[JMS] a
Request Reply is
+indicated by the presence of the `JMSReplyTo` header. This means the JMS
component automatic
+detects whether to use `InOnly` or `InOut` in the consumer.
+
+Likewise, the JMS producer will check the current
xref:latest@manual:ROOT:exchange-pattern.adoc[Exchange Pattern]
+on the xref:latest@manual:ROOT:exchange.adoc[Exchange] to know whether to use
`InOnly` or `InOut` mode (i.e. one-way vs request/reply messaging)
-You can specify the exchange pattern in DSL rule or Spring
-configuration.
