avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Schier <MSch...@bsquare.com>
Subject RE: SEDA vs. JMS?
Date Wed, 16 Oct 2002 15:56:32 GMT
You do not want to use SEDA/Sandstorm in its current materialization.  It's
a horrible codebase and has nothing remotely to do with COP. Two words:
research project. The underlying theory is very well thought through, but
the execution is based on research hacking (to prove the threory).  Berin
did a good job factoring out some concepts into the event package on top of
which I tried to build a framework and managing service.  Because it handles
a lot of underlying things for you it's going more into the heavyweight
direction.  Unfortunately there did not seem to be much interest, so I put
it off, since I am going to start a new job soon.  BTW. You should also
consider this difference: JMS = distributed based, SEDA = not-distributed.
Also, an app server you are building with SEDA has the characteristic of
only running in one thread, whereas conventional app servers utilize one
thread per connection and therefore will run out of resources at a specific
number of concurrent connections.


> -----Original Message-----
> From: Neeme Praks [mailto:neeme@apache.org]
> Sent: Wednesday, October 16, 2002 8:04 AM
> To: Avalon Developers List
> Subject: Re: SEDA vs. JMS?
> Berin Loritsch wrote:
> > 
> > The big difference is in the granularity of the components. 
>  The underlying
> > concept is the same.  However there are also some other 
> things to consider:
> > 
> > * SEDA is at a lower level, meant to build servers (like 
> Phoenix/Avalon)
> > * JMS is at a business level, meant to build applications
> > * SEDA can easily be dynamically rerouted at runtime
> > * JMS is usually for static solutions that work for a 
> particular solution
> > 
> > If you are looking to solve *business* problems, I would go 
> with JMS.
> > If you are looking to build a JMS server or some other 
> highly scalable
> > server, look to SEDA.
> Ok. This seems to be pretty clear now: I can build 
> high-performance JMS 
> server using SEDA, but I shouldn't try to build SEDA 
> framework using JMS.
> SEDA - low level framework
> JMS - higher level messaging server (can be based on SEDA)
> So, if I have a business problem that can be solved by using JMS, I 
> could use JMS. But if this problem is generic enough and I 
> want higher 
> performance, then I can just build a specialized server 
> (specialized for 
> solving this particular case) on top of SEDA, right?
> Got a bit clearer.
> Now I came up with another idea... I do not want to implement a full 
> blown specialized server from the start, instead, I would like to 
> convert some parts of the application to SEDA. Would that be feasible?
> What do I mean?:
> The application is a messaging server, with applications running as 
> MDBs: consuming incoming JMS messages and generating outgoing 
> JMS messages.
> Now, could I just decompose my MDBs into SEDA stages? So, 
> SEDA framework 
> would be running inside the MDB... should be quite possible...no? :-)
> How much work would that require and maybe you could give me some 
> pointers where/how to start? It would mean embedding Phoenix/Avalon 
> inside JBoss MDB...
> Neeme
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message