I have an open source enterprise middleware application that is expected to
process quite a huge number of transactions daily. My current architecture
(flow) looks thus:

JettyServer -> Preprocessor -> JDBCClient -> Processor ->  HTTPClient

I will like to make this reactive like this:

Camel-Vertx(HTTPServer) ->      Camel-Rx(JDBCClient)    ->      
Camel-Rx(Busines logic
Processor)      ->      Camel-Rx(HTTPClient)

My assumptions are:
Vertx HTTPServer has one or more threads that just accepts request from the
client
Vertx HTTPServer receives response to request on a separate thread/handler
Client waits for response to request nad connection is not cut off while the
HTTPServer has handed off request asynchronoulsy to Camel-Rx
Vertx HTTPServer asynchronously hands over the request to Camel-RX
JDBCClient
Camel-RX JDBCClient doesnt wait for/block on Database response/result, it is
available to process next request
Camel-RX JDBCClient proceeds  (Through callback or what not) to hand over
request to Camel-Rx Business Logic Processor
Camel-Rx Business Logic Processor proceeds to hand over request to Camel-Rx
HTTPClient
Camel-Rx HTTPClient doesnt wait for/block on Network response/result, it is
available to process next request
Camel-RX HTTPClient proceeds  (Through callback or what not) to return
response through the src travel path back to Vertx HTTPServer.

This way, the host threads are never block on I/O. The only time to be spent
is actually in the Camel-Rx Business Logic Processor where is is expected to
do marshalling, some encryption/decryption, message transformation and other
non I/O operations.

With my design above, will my assumptions be met?

Regards







--
View this message in context: 
http://camel.465427.n5.nabble.com/Reactive-Programming-with-Camel-Components-tp5765862.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to