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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
