>>There is a design fault with this approach IMO. You are moving what is
>>essentially infrastructure server/side functionality out of the middle
tier
>>and making it client's responsibility and introducing unnecessary
>>dependencies in the process.
>An EJB bean cannot start execution magically (all by itself).
>client process must be present somewhere to start execution of the >bean.
Most EJB containers do not even activate a bean until a client >instantiates
>the bean.
Correct. That is the EJB deficiency I was talking about. BTW there is
nothing magical about starting services without clients, see CORBA and RMI
specifications.
>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.
===========================================================================
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".
