> > 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. > > can you elaborate on this (heavyweight direction)? if I'm going to > undertake this, then I'll most probably need something more > lightweight > and I could try to implement something more lightweight...
What I meant is that if you used the stuff that I did you would use a more heavyweight solution than using the naked event package or sandstorm. It does away with the event handler interface which in my opinion is far too error prone when programming services, cause not type safe. The stage handler in my implementation uses (most efficient) reflection for delivering events to either one or more configered atomic methods or a whole interface of methods on one or more Avalon components. In this scenario you declare a component with a specific interface and all the interface methods are served from one or more specific queues and are managed by the SEDA based stage manager. The benefit is that you can melt together components into a SEDA architecture using an Avalon based configuration file. This is of course more heavyweight than using the Sandstorm/ Avalon event approach. > > > 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. > > Ok, this gives even more reason for embedding Phoenix/Avalon > inside MDB. > This way the system can still be distributed at JMS level, > but can take > advantage of SEDA concepts at single application (MDB) level. > Right now Sandstorm is not Avalon based. Berin is a commiter on the sandstorm sourceforge project, so this might change ... :-) You should also check out all the SEDA discussions on this list. (Just search for SEDA in the subject line) Marc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
