Hi,
I am not an expert in EJB2.0 yet, but what I would strongly suggest is some
enhancements in the handling of message-driven beans.
But please folks, tell me if I am wrong with some propositions, because they
might go against what Sun intended to do.
Well, so far I don't understand why these features are not supported for
message-driven beans :
1) dynamic selector for topic/queue which it listens to
2) multiple selectors (yeah I know, if we want an MDB listen to several
topics, why dont we just group these topics into one ? and yes, I can group
100 organisationally seperated topics in my application into just one,
holding thousands of messages - but then : what arguments are there against
allowing multiple subscriptions ? and multiple changeable subscriptions at
runtime ??)
3) dynamic definition of filters (is this already there ? I m not sure)
4) some control about when messages should be delivered : a time range :
let's say : "Deliver this message and trigger an MDB at least in 10
seconds) - and here I might be fundamentally wrong and go against the
container-managed-resource paradigm in EJB.
5) concerning EJBs generally : is there a way to find out the system
resources a particular component (EJB) is consuming at a given moment of
time ? (cpu, memory, or %cpu_in_total_clustered_environment,
%memory_in_total_clustered_environment)
6) concerning stateful session beans : I am missing one kind of bean in
EJB - the "being" - I am not intending to have a bean run all the time. But
at least what I want is to get its state back whenever I want. It should be
possible to specify a stateful session bean "mutant" which does only get
passivated, and not removed until a specified "range of time til eviction".
For now, I have to resolve this by persisting the state of a stateful
session bean every time into the database, to make sure it does not get
evicted from the container. If the "being" is "reincarnated" 2 hours after
the 1st calling client disappeared, I want its state back.
and now a fundamental one :
7) Schedules, Timers ! the whole EJB model is designed to be passive and to
REACT rather than act. There always has to be a client "kicking" the system
to act. It is a big workaround to realise something like a living component
in there, which can wake up itself, bring itself to life, and then do
things, without the need for the kick of a client. At least EJB servers
should provide one common mechanism for scheduled actions. This way one
could implement a scheduler braught to life each second, and checking for
which components in there should be woken up to ACTIVELY check for changed
situations (the only thing changed might be the time since the last wakeup).
Ciao, Jubin Zawar
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
