Just to set the record straight ...
It is possible today for an EJB vendor to provide an asynchronous
implementation of EJB method calls with no return value, no application
exceptions and with an appropriate transaction attribute, i.e. nothing
prevents a container implemention from reliably queueing such calls and
delivering them later.
No change to the EJB architecture is needed to support this.
The marketplace can decide how important such functionality is just as
it decides how important it is to automatically distribute method calls
across multiple server instances.
Although there is a minor overlap between the above and EJB/JMS
integration, this integration provides a much more flexible model of
asynchronous communication between components that cannot be effectively
provided 'underneath' RPC.
-- Mark
Peter Michael wrote:
>
> 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".
