Hi,
I'm having a similar problem. Using SpyderMQ to set up a
temporary queue for asynchronous events from my stateful
session bean is simple, but doesn't solve the problem of
background processing at the server.
Since I'm not yet quite ready for message beans, some
kind of non-EJB service at the server is needed. This
would (of course) go beyond the EJB specification, and
thus be non-portable.
What I've been thinking about was to write a JMX service
for deferred bean invocations. Clients of this service
are beans running at the server. The service API could be
as simple as:
void invokeLater(long time, EJBObject target,
Method method, Object[] args);
When called, the method would be invoked at the target
object with the given arguments at the given time.
But I am a bit in doubt about the context(s) of the
deferred invocation: Clearly the current transaction
context cannot be propagated in the invocation, or
checked behaviour would be impossible.
But how about the security context? Would there be any
(real or potential) problems grapping this from the
SecurityAssociation and setting it for the invocation?
Or would it be better to explicitly pass the principal
and credentials to use for the invocation?
Best Regards,
Ole Husgaard.
"Kenworthy, Edward" wrote:
>
> 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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
