I would like to add reentrant session beans to the wish list
so that writing multithreaded clients to EJB session beans
becomes easier.
Frank
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Peter Michael
Sent: Monday, November 22, 1999 11:20 AM
To: [EMAIL PROTECTED]
Subject: The Future of EJB (Thoughts on what the EJB 2.0 spec should
conta in. READ THIS!)
Hi,
I would like start a little discussion here about what should be added in
the EJB
2.0 spec. The reason for this is, that I recently had a little email
conversation
with someone on this list, who told me that Mark Hapner (who wrote the EJB
spec
along with Vlada Matena and who, I hope, reads this) isn't apparently very
fond of
the idea of asynchronous EJB calls. He seems to think that JMS, the Java
Messaging
Service, is sufficient for our needs. I beg to differ here.
My EJB 2.0 Wishlist (right in time for christmas ;)
Asynchronous calls:
- It should be possible to call EJBs asynchronously. It should be
possible to
have one, multiple or no return values.
- It should be possible to cancel pending calls (for beans that
support this).
- It should be possible to suspend/resume calls (for beans that
support this), and
a bean may even be able to do this itself (i.e. suspend itself and
wake up when it
gets a message from JMS).
- The caller should be able to wait for a return value and
optionally specify
a timeout.
ejbTimeout Function:
- EJBs should have an ejbTimeout-Function that allows them to notify
their client
and maybe other EJBs of the timeout. ejbPassivate is not
sufficient, because it
is a big difference if a statefull session bean is swaped to disk
or times out.
The home interface should provide a getTimeout() function, so a
client can
determine when a approx. will time out.
Grouping of EJBs:
- It should be possible to group EJBs within an application. For a
given client,
there should always be two standard groups: All EJBs in the
current application and
all EJBs created by this client. It should be possible for a bean
to list all bean
instances within its group and obtain references to them.
Defined Error-Handling:
- It should be possible to a install a default error handler for
each group that pops
in when a bean in this group has a fatal error or another
specified condition
(timeout, low memory condition,...) , so we can do some
recovery/notification within
the container.
And/Or
Concurrent Timeouts:
- It should be possible to timeout multiple EJBs together, i.e. when
one EJB times
out, all other EJBs in this group timeout, too. (This could be
handled by an error
handler described above.)
Singleton EJBs:
- It should be possible to have singleton EJBs that are not only
unique to an
application running in a single container but unique to the whole
application
across multiple JVMs.
Leases:
- For non-web clients it would be great to have leases (like in
JINI) for both
the client and the container. So the container could determine if
a client
crashes and free resources and the client could determine if a
container crashes
and react properly to this. This should of course be optional.
[Add your wish here... (I leave the whole stuff about entity beans to other
people...)]
Before someone replies that asynchronous calls could be simulated/handled by
JMS, I would
like to say the following: To achieve the functionality I described above
with JMS, we would
have to do a lot of non-trivial coding. Why do I want async calls? Easy of
use, performance,
less coding. Just try to answer the following question: When I make a async
call to an EJB
that has crashed, I would get an exception. When I send a message instead,
how do I notice
the EJB crashed? There are so many subtle differences between an async call
and sending a
message that require me to have both mechanisms. Each has a right of it own.
Asynchronous call are so fundamental, we should not all be required to go
through a hurdles
to create a framework ourselves, if we need them. This is clearly the job of
SUN and the
EJB container implementors. We users should concentrate on our business
logic, not
frameworks.
Bye,
Michael
---
Everything Zen? I don't think so.
===========================================================================
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".
===========================================================================
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".
