>>> But this is not in current EJB 1.1 spec. Or did I miss some-
>>> thing? I think there are only about five lines about JMS
>>> in the current spec. Thus, the behavoir is undefined and
>>> not guaranteed to work with different EJB containers.
>>> (Even though containers should work the way that bernd
>>> described.)
>>EJB/JMS integration is unspecified, but nothing prevents you from making
>>a simple proxy that delegates incoming JMS messages to beans. And then
>>you would communicate with the bean through the EJBObject, which would
>>give the behaviour Bernd outlined (as the proxy is only
>>yet-another-client).
>
>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).
A 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.
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.
===========================================================================
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".
