[camel] Comments on MINA coment

["dr.jeff" <jl...@systechnologies.com>]

I was attracted to Camel by the existance of the MINA component, but I now
see that it has some deficiencies.
Very generally there can be 4 kinds of MINA endpoints:
1) acceptors ("server sockets", that accept connections) that initiatiate
request/responses,
2) acceptors that wait for requests (eg, HTTP servers),
3) listeners (i.e., connection initiators) that initiatiate
request/responses (eg. HTTP clients), and
4) listeners that that connect, then wait for requests, and then respond.
It would be nice if Camel could provide a transparent easy-to-use way to
plug and play with any of these four.
-- 
View this message in context: http://www.nabble.com/-camel--Comments-on-MINA-coment-tf3618836s2354.html#a10104315
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: [camel] Comments on MINA coment

["dr.jeff" <jl...@systechnologies.com>]

Interesting MINA "hot spots" are messageReceived() and session.write() (and
also exceptionCaught, but ignore it for now).
The Camel components can either do (1) acceptor.bind(address, handler,
endpoint.getConfig());,
or they can do (2) connector.connect(address, ioHandler,
endpoint.getConfig());
You have that already. But type (1) components can either do
session.write(body) during process(Exchange exchange), or they can do
processor.process() with the object from messageReceived(), and similarly
for type (2) components. 
Right now you just have that wired up in one of the two ways.
Hope that's clear???


James.Strachan wrote:
> 
> On 4/20/07, dr.jeff <jl...@systechnologies.com> wrote:
>> I was attracted to Camel by the existance of the MINA component, but I
>> now
>> see that it has some deficiencies.
> 
> I hope we can work on the camel-mina module to integrate with more of
> the capabilities in MINA. Hopefully with some help from MINA experts
> like yourself we can figure it out :)
> 
> 
>> Very generally there can be 4 kinds of MINA endpoints:
> 
> I guess we could wrap these different types up as different kinds of
> Camel component/endpoint? We just need to figure out a clean mapping
> between the MINA model and the Camel messaging & endpoint model
> 
> 
>> 1) acceptors ("server sockets", that accept connections) that initiatiate
>> request/responses,
>> 2) acceptors that wait for requests (eg, HTTP servers),
> 
> I'll come back to these at the end...
> 
> 
>> 3) listeners (i.e., connection initiators) that initiatiate
>> request/responses (eg. HTTP clients), and
> 
> So thats like a Producer on an existing camel-mina endpoint right?
> 
> 
>> 4) listeners that that connect, then wait for requests, and then respond.
>> It would be nice if Camel could provide a transparent easy-to-use way to
>> plug and play with any of these four.
> 
> This seems like a Consumer on an existing camel-mina endpoint right?
> 
> 
> So 3 & 4 are what we have today I think? (Apologies if I
> misunderstood; I'm a bit of a newbie with MINA). So it mostly seems
> like we need to better support the ability to have 'servers' like a
> server socket / HTTP server which wait for connections to be initiated
> then spin up separate endpoints for each connection?
> 
> In terms of the MINA API I think this seems more like we need a kind
> of Camel Endpoint which maps to an IoAcceptor and listens for new
> connections (via IoServiceListener right?); then when a new connection
> is established, we spin up a new endpoint and Consumer?
> 
> Or do you see this as mapping a different way? To put this into
> context we have camel-jms which can spin up a pool of threads
> consuming inbound JMS messages concurrently; I'd always envisaged a
> servlet based endpoint where we could map a servlet URI to a camel
> endpoint for processing in a similar way.
> 
> -- 
> James
> -------
> http://macstrac.blogspot.com/
> 
> 

-- 
View this message in context: http://www.nabble.com/-camel--Comments-on-MINA-coment-tf3618836s2354.html#a10106021
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: [camel] Comments on MINA coment

[James Strachan <ja...@gmail.com>]

On 4/20/07, dr.jeff <jl...@systechnologies.com> wrote:
> I was attracted to Camel by the existance of the MINA component, but I now
> see that it has some deficiencies.

I hope we can work on the camel-mina module to integrate with more of
the capabilities in MINA. Hopefully with some help from MINA experts
like yourself we can figure it out :)


> Very generally there can be 4 kinds of MINA endpoints:

I guess we could wrap these different types up as different kinds of
Camel component/endpoint? We just need to figure out a clean mapping
between the MINA model and the Camel messaging & endpoint model


> 1) acceptors ("server sockets", that accept connections) that initiatiate
> request/responses,
> 2) acceptors that wait for requests (eg, HTTP servers),

I'll come back to these at the end...


> 3) listeners (i.e., connection initiators) that initiatiate
> request/responses (eg. HTTP clients), and

So thats like a Producer on an existing camel-mina endpoint right?


> 4) listeners that that connect, then wait for requests, and then respond.
> It would be nice if Camel could provide a transparent easy-to-use way to
> plug and play with any of these four.

This seems like a Consumer on an existing camel-mina endpoint right?


So 3 & 4 are what we have today I think? (Apologies if I
misunderstood; I'm a bit of a newbie with MINA). So it mostly seems
like we need to better support the ability to have 'servers' like a
server socket / HTTP server which wait for connections to be initiated
then spin up separate endpoints for each connection?

In terms of the MINA API I think this seems more like we need a kind
of Camel Endpoint which maps to an IoAcceptor and listens for new
connections (via IoServiceListener right?); then when a new connection
is established, we spin up a new endpoint and Consumer?

Or do you see this as mapping a different way? To put this into
context we have camel-jms which can spin up a pool of threads
consuming inbound JMS messages concurrently; I'd always envisaged a
servlet based endpoint where we could map a servlet URI to a camel
endpoint for processing in a similar way.

-- 
James
-------
http://macstrac.blogspot.com/