Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E1890E81E for ; Sat, 2 Feb 2013 08:56:24 +0000 (UTC) Received: (qmail 9313 invoked by uid 500); 2 Feb 2013 08:56:23 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 9270 invoked by uid 500); 2 Feb 2013 08:56:23 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Delivered-To: moderator for users@camel.apache.org Received: (qmail 24803 invoked by uid 99); 2 Feb 2013 08:12:32 -0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,SPF_SOFTFAIL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: softfail (nike.apache.org: transitioning domain of rakesh_sharma66@hotmail.com does not designate 216.139.236.26 as permitted sender) Date: Sat, 2 Feb 2013 00:12:05 -0800 (PST) From: Rakesh Sharma To: users@camel.apache.org Message-ID: <1359792725000-5726809.post@n5.nabble.com> Subject: Event Driven Use Case MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org I am implementing a flow(route) using camel that requires interaction with multiple external systems via RestFul service calls. These service calls provide only an ACK back. The actual response is sent by external system by making another service call back to my application. My app is running in tomcat container on multiple machines fronted by a load balancer. The subsequent steps of my route are dependent on the response of the external service call. Having a load balancer complicates it further as external service response may not come to the same machine where the original service call was made from. I also need to timeout the exchange processing in case external service response does not come back within a specified time interval. I am thinking of using following strategy to solve this problem: 1. Break big route into multiple small routes. The last step of each small route will make the service call to the external system. Essentially, I will have as many routes as number of calls to external systems. The endpoint of every small route (other than the initial one) will be the service end-point where external service is going to come back with its response for the request that was sent by the last step of the previous route. 2. Serialize the exchange just before making the service call and save it in DB with UUID as key. 3. Create a consumer on SEDA endpoint "seda:{uuid}" with a timeout. It is being created only to track if external service provided a response back within the expected time interval. 4. Make the service call to external system with UUID as part of the request. 5. Retrieve the saved exchange state(using UUID) and remove the entry from DB as soon as external service responds(response has the same UUID that was passed with the request) back by invoking the next route endpoint. The route has the previous state(retrieved from DB) and response from the external system. It can proceed further now by merging the previous state and the external service response. We know that response did not come within expected interval if DB does not have an entry for the UUID extracted from the service response. 6. The SEDA consumer will timeout and will make a check if DB still has the entry. If entry exists we know that external service response has not come within the expected interval. The entry from DB will be removed. This is a very heavy traffic applications and I am not sure if I am doing it in right way. Any suggestion will be highly appreciated. Using messaging system is not an option due to many factors outside of my control. Thanks, Rakesh -- View this message in context: http://camel.465427.n5.nabble.com/Event-Driven-Use-Case-tp5726809.html Sent from the Camel - Users mailing list archive at Nabble.com.