Perry Hoekstra wrote:
> Ian McCallion wrote:
>
> >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?
Seems to me you have written the question slightly wrong. Foo.A spawned a
message - agreed. But we need to suppose that this message goes to some other
application which eventually replies. It is the existance of this reply message
that Foo.A needs to be informed of. Andrzej Jan Taramina discusses this in his
EJBAsync proposal, see http://www.chaeron.com/software.html .
> 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?
The message spawned by Foo.A would contain an object reference to Foo.A which to
the legacy app is opaque binary data that it merely returns in its reply. The
reply gets back to the message monitor which can therefore inform Foo.A (see
EJBAsync) although the message monitor needs effectively to be PART OF THE
CONTAINER in order to do this.
> >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?
Not today, no. But desireable, yes.
> >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.
I think Integration of time into the monitor is important, because if the
expected reply never arrives your session bean may want to take some alternate
action based on a timer event.
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
