On Mon, 29 Nov 1999, Lahooti, Hamid wrote:
> >Therefore, to have a bean listen for JMS messages is redundant. The
> >client that instantiated the bean can listen simpler (tying up less
> >resources) and not violate any EJB specifications. Then for each >message
> recieved call appropriate methods on the bean instance.
>
> That's pushing middle tier infrastructure functionality out to the clients.
> Clients can't provide services. That's for servers to do.
I agree 100%. In fact, if the _ONLY_ thing provided by the EJB/JMS
integration is message dispatch from a JMS queue to an EJB instance, I'll
be satisfied.
One of the selling points of app servers is manageability. One of the
selling points of transactional message queueing systems is rock-solid
reliability. If I have to write my own client to poll a queue and invoke
EJBs when messages arrive, I've done several things:
1) I've introduced a potential performance bottleneck into the system.
2) I've made my code responsible for guaranteeing that the message will be
handled successfully, retrying in the event of failure, etc.
3) I've got to build infrastructure to start, stop, and manage the
execution of the message dispatch process.
4) I've introduced another element into the production configuration. This
element will have to be tracked, version-controlled, documented, and so
forth.
============================================================================
Tom Valesky -- [EMAIL PROTECTED] -- http://www.patriot.net/users/tvalesky
===========================================================================
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".
