Asynchronous callbacks

[aleksab]

How can i achieve asynchronous callbacks in a stateless/statefull bean?

Scenario: A client send a request to a bean (ie do some processing of some large data). The bean returns a answer immidiately to the client, but wants to be able to tell the client on the progress and the final results. The client has a method which is dedicated to handle these callbacks. How can the bean send asynchronous callbacks to the client?

I've tried by sending the Method as a argument to the bean:
public String getAsynhcString(Method client, String test)

and the client invoke this by:
test.getAsynhcString(this.getClass().getMethod("callmeback", String.class), "hello");

The callmeback method of the client is on this form:
public void callmeback(String res)

However, when trying this, I get a marshalling exception: java.io.NotSerializableException: java.lang.reflect.Method
which is very unfortunately.

wondering if there are any suggestions on how i should accomplish my goal?

[wolfgangknauf]

Hi !

I think in your scenario a message queue would be helpful:
-in the server a queue is configured.
-when the session bean method is called it starts pushing status messages to the queue
-the client registers to the "other end" of the queue and receives the messages, until some "Finished" message arrives.

Does this help ?

Wolfgang

[aleksab]

I've thought about it, but I don't want anybody to be able to listen to the replies/answeres. :-( It also introduce more overhead, which I don't really want.

[aleksab]

I managed to do it with a little "hack".

Instead of passing the Method as an argument, i passed the client object itself as an argument. This means that the method in the bean was changed to:

public String getAsynhcString(Object client, String test)

The client calls the bean with:

String tmp = test.getAsynhcString(this, "hello");

This works, and in this example it would be:

Method met = client.getClass().getMethod("callmeback", String.class);
met.invoke(client, "lovely");

There are several downsides to this, however. I have to extract the method, which means that i must know the method name and arguments. This is bad for generic method callbacks. It could be solved by annotations I suppose, but that only introduce more "hacks".

Anyone know how I can do if differently? Suggestions and ideas are much appreciated.

[aleksab]

Noticed another big drawback. Since the object isn't a RMI object, the method on the client is never called, but the copy on the bean side.

Would it be sufficient to pass a RMI object?

[aleksab]

Isn't there anybody who have done something similar?

If there is an obvious solution to this problem, please tell me, because I can't see it..

:)

[konstantin.ermakov]

Hi!

I was planning to implement it. My idea was to implement the MDB, which is listening to the messages and giving the result back to the client, i.e. during the execution your state/less/full bean sends messages to MDB, MDB does the rest.

[aleksab]

What about security?
Couldn't anybody sign up to a queue and listen for replies?

But the only suggestion i've heard so far..

[konstantin.ermakov]

We have implemented our own security mechanism, but I think there should be something in JMS implementation.

[aleksab]

Ended up by implementing a bit more logic in the client.

Made a generic class which is kicked of as a thread in the client. The thread blocks, but not the client, so everything is fine.

Thanks for all the help and suggestions btw.