From 3142f0b67318c6153dad2898db70ef265dc2aaf4 Mon Sep 17 00:00:00 2001 From: Oleg Zhurakousky Date: Tue, 28 Sep 2010 16:49:26 -0400 Subject: [PATCH] INT-1474, added initial documentation to explain the implications --- src/docbkx/gateway.xml | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/src/docbkx/gateway.xml b/src/docbkx/gateway.xml index 178d16db7d..bd7df3720e 100644 --- a/src/docbkx/gateway.xml +++ b/src/docbkx/gateway.xml @@ -31,6 +31,7 @@ void placeOrder(Order order); }]]> + ... as well as method sub element if yuo prefer XML configuration (see next paragraph) It is also possible to pass values to be interpreted as Message headers on the Message @@ -82,6 +83,7 @@ by mapping it to a Message. To accomplish this our Gateway provides support for Exception mappers via the exception-mapper attribute. + - + + + + Exposing messaging system via POJO Gateway is obviously a great benefit, but it does come at the price so there + are certain things you must be aware of. + + We want our Java method to return as quick as possible and not hang for infinite amount of time until they can + return (void , exception or return value). When regular methods are used as a proxies in front of the Messaging + system we have to take into account the asynchronous nature of the Messaging Systems. This means that there might + be a chance that a Message hat was initiated by a Gateway could be dropped by a Filter, thus never reaching a + component that is responsible to produce a reply. Some Service Activator method might result in the Exception, + thus resulting in no-reply (as we don't generate Null messages).So as you can see there are multiple scenarios + where reply message might not be coming which is perfectly natural in messaging systems. However think about the + implication on the gateway method.  The Gateway's method input arguments  were incorporated into a Message and + sent downstream. The reply Message would be converted to a return value of the Gateway's method. So you can see + how ugly it could get if you can not guarantee that for each Gateway call there will alway be a reply Message. + Basically your Gateway method will never return and will hang infinitely. (work in progress!!!!) +One of the ways of handling this situation is via AsyncGateway (explained later in this section). Another way of handling it is to explicitly set the reply-timeout attribute. This way gateway will not hang for more then the time that was specified by the reply-timout and will return 'null'.  + +
Asynchronous Gateway