Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Tue, 4 Nov 2003 17:08:08 +0000 (GMT)
From: Bruce Snyder <ferret@frii.com>
To: geronimo-dev@incubator.apache.org
Subject: Re: Status of JMS
In-Reply-To: <38747CD6-0EE6-11D8-9890-000A959D0312@yahoo.co.uk>
Message-ID: 
 <Pine.LNX.4.44.0311041651580.23924-100000@pclnxbsnyder.digitalglobe.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This one time, at band camp, James Strachan said:

JS>On 4 Nov 2003, at 16:22, Noel J. Bergman wrote:
JS>>> I'd rather explore JMX, I've been looking at JBOSS 4 and its JMX
JS>>> architecture seems to describe what I'd like to see James have.
JS>>
JS>> JMX and JMS don't serve the same purposes.  JMS *might* (and I stress 
JS>> that
JS>> it is only a possibility, and not one that I'm overly convinced about)
JS>> provide a spool implementation.
JS>>
JS>>> I'm certainly not convinced that JMS is really the best approach. It 
JS>>> would
JS>>> be sadly ironic if we end up with James performance suffering because 
JS>>> of
JS>>> JMS queue issues.

Unless there's a damn good reason for it (and it's entirely possible that
I'm missing something) I disagree that JMS should be used from intra-VM
messaging between threads. AFAIK, the intent of JMS is inter-VM messaging
for purposes of decoupling. Please correct me if my understanding
is wrong.

JMX is another issue entirely. JMX is for managability of components. It's
got nothing to do with messaging.

JS>I doubt that a decent JMS implementation would ever be slower than a 
JS>hand-hacked-together communication mechanism (especially if things like 
JS>flow control, auto-reconnect and so on are requirements). Though it 
JS>depends what you're trying to do I guess.
JS>
JS>
JS>>> OTOH if it works I'm for it. :-)
JS>>
JS>> That is my position, as well.  Considering that I used to write 
JS>> real-time
JS>> embedded kernels for a living (albiet a couple of decades ago), 
JS>> performance
JS>> is never far from my mind.  Personally, I think that JMS is overkill, 
JS>> but it
JS>> has been recommended that we look at it, so I'm asking the geronimo 
JS>> team
JS>> what the status is so that we can evaluate.  I've other alternatives in
JS>> mind, as well.
JS>
JS>I'd use OpenJMS or JGroups for now. There is no JMS implementation 
JS>inside Geronimo yet & I can't imagine there would be one for a while.

As far as JMS is concerned, I'd like to use OpenJMS simply because I use
it now and I really like it's feature set. But I'm not sure what issues
lie in wait from the Intalio side. The other one that I'm interested in
JORAM from ObjectWeb.

JGroups is out of the question for Geronimo because of license. It's LGPL.

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

The Castor Project 
http://www.castor.org/

Apache Geronimo 
http://incubator.apache.org/projects/geronimo.html