>> For example:
>>
>> I have an EJB bean (Foo.A) that goes about its merry business and
>> somewhere it does some processing that places a message on the
>> queue. Now I have a message monitor that implements a listener.
>> This listener is informed that a message was placed on the queue
>> and it receives a copy of that message. Through various
>> mechanisms, it determines that EJB bean Foo.A should be informed
>>
>> However, because of the one-client/one-bean rule (talking stateful
>> session bean (SSB) here), the listener cannot inform Foo.A of this
>> event. If it invoked, it would inform Foo.B which would have no
>> clue what to do because many times these messages are only
>> important in the context of the bean's currently held state.
>>
>> The listener would have to route the notification to client and
>> the client would have to inform the Foo.A bean. Anybody want to
>> give odds on how well such a round-robin scheme would stand up to
>> the rigors of a production distributed environment?
>
>You've assumed a very simplistic message monitor, and I hope we'll get something
>much better out of Sun's EJB/JMS integration work. There's no technical reason
>why the message monitor should behave like a client of any bean it sends
>notifications to. So if you assume that the message monitor can start new
>instances and/or notify existing bean instances of the arrival of messages
>without automatically being the client of the instances, then in your example,
>Foo.A could be notified of the arrival of the reply message.
Now, you lost me!
If Client.A created an instance of Foo, called Foo.A (this is a Stateful Session Bean)
and invoked some behavior which spawned a message, this message send was caught by the
message monitor, how would the message monitor inform Foo.A of its existence?
It could route the information through Client.A if it had a reference. Are you saying
that the message monitor could also route the notification to Foo.A bean directly?
How would the message monitor can visibility to Foo.A? Did Client.A give the message
monitor a reference?
>
>Of course, when using (synchronous) RMI between client and server the client
>will have to poll Foo.A to find out about the reply. But by using asynchronous
>communication also between client and EJB server we could avoid this ugliness
>too.
Possible given the current state of the specification and its implementation by
vendors?
>For completeness, the message monitor should really be an event monitor and
>should support other types of events as well, eg time, and container/JVM events.
No, I am looking for this message monitor to do one thing and do it well. I would
like to swap this out for something better like Sun's EJB/JMS integration product at
some point in time.
Thank you for your time,
Perry Hoekstra
Consultant
Talent Software Services
Email: [EMAIL PROTECTED]
Get your FREE Email at http://mailcity.lycos.com
Get your PERSONALIZED START PAGE at http://my.lycos.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".
