Hi Sacha
The client code doesn't necesarily need to run on the client machine. How
about a non-EJB app (called by RMI?) on the same box as the appserver ?
However, it sounds like JMS is the right approach so go for it.
Edward
-----Original Message-----
From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
Sent: 05 January 2001 09:13
To: jBoss
Subject: RE: [jBoss-User] Callback to clients
Hello Edward,
I see your point. But in fact, the example I gave was just an example. In
reality, my problem is more tricky and, as in a workflow, components may
need to speak to componenets which in turn may need... Consequently, the JMS
approach fits perfectly to suppress this potential "infinite" loop.
Nevertheless, the fact is that if we want to cleanly solve the MVC pattern
with the model being the EJB, I do not see a solution direclty coming in my
mind appart the JMS (quite heavy). But I am not sure your solution (a client
thread) is a perfect candidate : what if may have 20 potential callbacks
from different parts of my client? 20 threads? a "callback controller" on
the client side needing only one thread?...
Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Kenworthy, Edward
> Envoyé : jeudi, 4 janvier 2001 14:55
> À : 'jBoss'
> Objet : RE: [jBoss-User] Callback to clients
>
>
> Thanks goodness for that. Is beginning to think my suggestion was just too
> elegant and simple with all these rather complex suggestions using RMI,
> bespoke beans and JMS.
>
> Use a client-side thread !
>
> -----Original Message-----
> From: Karl-Fredrik Blixt [mailto:[EMAIL PROTECTED]]
> Sent: 04 January 2001 12:30
> To: jBoss
> Subject: Re: [jBoss-User] Callback to clients
>
>
> Sacha Labourey wrote:
> >
> > This does not seem to fit in the EJB concept. Am I wrong?
> >
> Currently, no. JMS in the upcoming 2.0 spec should be what you need.
>
> > How to implement these call-back and server background
> processing with the
> > EJB?
> >
> You could have the client register itself as an RMI object, pass itself
> along (thus being converted into a stub), then have the EJB call a
> service passing the stub along as a parameter, and then return
> immediately. The service that performs the actual work (eg downloads the
> file) would then call the client through RMI when it is done:
>
> client EJB stub service
> | | |
> | foo() | |
> |------>| | bar() |
> | |------------->|
> | | |
> | |
> Call has returned to the client.
> The service now performs the actual work (timed, new thread in bar() or
> whatever).
> | |
> | | |---
> | | | | baz()
> | | |<--
> | | |
> | | done()|
> | done() |<------|
> |<-------------|
> | |
>
> Hope it helps somewhat. Let me know if I'm talking garbage, guys.
>
> Regards,
> /Kalle
> --
> Karl-Fredrik Blixt
> Computer Science Engineer
> Homepage: http://www-und.ida.liu.se/~karbl058
> Telephone: +46-(0)13-17 99 29
> Cellular: +46-(0)739-87 11 03
> UIN: 4744258
>
> "Consider the situation. There you are, forehead like a set of
> balconies, worrying about the long-term effects of all this new 'fire'
> stuff on the environment, you're being chased and eaten by most of the
> planet's large animals, and suddenly tiny versions of one of the worst
> of them wanders into the cave and starts to purr."
> -- Why humans like cats (Terry Pratchett, The Unadulterated Cat)
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> List Help?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
