Stu suggests: > Async calls are cool, but do they really belong in the EJB spec? Many async > features can be implemented with a client-side library on top of RMI, which > would work for distributed Java objects in general, instead of just EJB. Of > course, there is some benefit to standardizing the "poll" and "callback" > interfaces of a generic async library, but this could be done as a separate > spec which leverages RMI. I created a preliminary spec for Async support in EJB, in some detail, with the input of some of the participants here on the list. If you are interested it can be found at http://www.chaeron.com in the download section. ---------------------------------------- Richards replies to Mark: > MARK HAPNER wrote: > > 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. > > Exactly. So if I understand Mark's position correctly (correct me if I'm > wrong here), he does not think that asynch RMI is a bad thing, it's just > that it should not be *the* integration between EJB/JMS. It is a good > complement to beans being able to be message consumers, but should not be > the *only* integration specified in EJB2.0. The problem I have with this is that vendors may do just that...but will invariably add some of their own "bells and whistles" (such as a way to return a result from an Async bean) in response to real world needs of their customers. This causes different vendors implementations of EJB to fork and become incompatible, which rather defeats the purpose of having a standard anyway. IMNSHO, if users want/need Async (or any other feature for that matter), then a standard way of providing such functionality should be documented in the spec, rather than forcing vendors to provide incompatible API's for the same functionality. There seems to be a tendancy in the EJB spec towards theoretical correctness at the expense of practicality and simplicity at times. CORBA is a perfect example of this...it is a wonderful component spec....but runs way late and the complexity precludes many firms from learning it and using it. EJB isn't that bad...but it is definitely heading in that direction somewhat. Given the tight deadlines and market pressures that most customers face in trying to deliver new applications, simplicity and practicality are almost mandatory. Just some thoughts from the trenches and more than a few years of experience.... Andrzej Jan Taramina Chaeron Consulting Corporation Chaeron: - http://www.chaeron.com =========================================================================== 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".
