Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (herse.apache.org: domain of james.strachan@gmail.com
 designates 66.249.82.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=SxAhX+/SM2xfYqF+7LFOaLmzPl5ypEjiK3fY1ht/ZW2JZGZoq+w0yivVwfya4zwETktjwBnVGs5kUfuW5DboZBWJusyR+lXmvbuWMy0h5OfpYuuBvacbA/MvshKxhcTdI5i5LvPuqeBAVjEv6zDLD1IuT3bS6Hvsv2IM+T6oJRs=
Message-ID: <ec6e67fd0704200853p69524439jab4618a5c1ef32b7@mail.gmail.com>
Date: Fri, 20 Apr 2007 16:53:14 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: users@activemq.apache.org
Subject: Re: [camel] Comments on MINA coment
In-Reply-To: <10104315.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <10104315.post@talk.nabble.com>

On 4/20/07, dr.jeff <jlansing@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/