I totally support Peter on this...
Async calls are crucial.... !!!
I had a chat recently with a J2EE tech evangelist from SUN at a SUN
Technology Days conference.
I told him that I've got the impression that SUN EJB architect team is not
listening to EJB developers, people who are trying to develop real complex
business applications and who are facing with EJB architecture lack of
specifications (I suppose they are at least listening to EJB Server vendors'
technical team).
The evangelist told me that I was right and that Sun is trying to change the
situation.
So I hope this is going to happen and that Vlada and his team are open to
this.
I know spec definition is a long process but EJB spec definition process
needs to be a little bit quicker. Most of EJB server vendors already had
Entity bean available when Spec 1.0 was out.
Remember the CORBA story....
I think most of us are in a crucial phase today about product architectures
choice (EJB or not).
Daniel
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Michael
> Sent: Monday, November 22, 1999 5:20 PM
> To: [EMAIL PROTECTED]
> Subject: [EJB-INT] 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".
