Reactive Programming with Camel Components

[Naira & Kobo <le...@gmail.com>]

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.

Re: Reactive Programming with Camel Components

[Anton Hughes <ku...@gmail.com>]

You might find these of interest:
http://camel.apache.org/rx.html
http://camel.apache.org/async.html

On Thu, Apr 16, 2015 at 4:24 PM, Naira & Kobo <le...@gmail.com>
wrote:

> 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.
>