Hi all,
Here's our wish list:
- Bulk operations (across many objects): create/update/delete
- Global and standardized query service
. Spans more then a single server/home
. Supports polymorphic queries
. Supports OQL
- Object change notifications: create/update/delete. Notifications should
include
the new/updated attributes and the old attributes for update.
- List service:
This is a more advanced service, and is needed commonly in network
management applications, not sure if other domains need it:
Support for dynamic lists on clients, where the server maintains a
large list, sorted and filtered, and the client is notified of changes in
a specific page (portion of the list). In network management a good
example
is a list of open alarms. There may be many, but the GUI views only a
portion,
and in a scalable system, notifications should be made only for the
portion
viewed by the user (+ some possible buffering)
I'll be very interested to know if others feel the need for these services,
and had to implement some of them in their own infrastructure, and of course
will be most interested to hear from Sun regarding their plans.
Doron
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Michael
> Sent: Monday, November 22, 1999 8: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".
