activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [camel] Comments on MINA coment
Date Fri, 20 Apr 2007 15:53:14 GMT
On 4/20/07, dr.jeff <> 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.


View raw message