Implementing a bidirectional protocol with EJB

[grmiked]

Hello,

I am trying to implement a bidirectional protocol communication between a server and various clients using JBoss. The server resides on a JBoss server and contains a stateful session bean exporting functions that the clients can invoke.

I want to also enable the other way communication. The client should also be notified about some events that happen at the server. This means, the client should also be some kind of a server. I d not want to migrate the client to ejb and make it in turn a server using jboss, I want it to remain thin. The only workaround I have found until now was to create an RMI server on the client.

Does it exist any other clearer way using for example some kind of EJB callback functions? I want to emphasize that I need a synchronous communication and the JMS is out of question because as far as I know it facilitates only asynchronous message passing throuh a queue (or maybe not only?).

Thanks in advance!

[billstclair]

I don't know any way of doing what you want directly, but I need such a facility in my application so that long-running server operations can report progress to be printed in a client dialog. Here's one idea I have for doing it.

@Remote
interface Notify {

Object getNotification();

void notify(Object message);

}
A client thread calls getNotification() and hangs until it returns.

The server calls notify() when there's something to send back to the client. This causes the client's call to getNotification() to return the "message".

If notify() is called when there is no current getNotification() call, the message is queued waiting for the next one.

You probably also need a clearNotificationQueue() method.

The major drawback of this approach is that every client with an outstanding getNotification() call hangs on to a server thread while the real work happens in another. It also costs an idle client thread, but that's how my application already works.

I just need to pass strings back to the client. If you have a number of different logical operations to do on the client, you'll need more structure to your messages and client-side code to dispatch them to the action methods.

My current application (Java client with Progress 4GL on the server) has a custom TCP server on the client. It passes the listening port to the server, which connects to it and send messages via raw TCP. This works fine in a local area network, but fails when a firewall is involved, hence I don't want to do it this way any more.

I haven't written any code for this yet, but I thank you, sir, for prompting me to think about how to do it.

[billstclair]

This ended up being more work than I thought it would be, mostly due to my non-understanding of how EJB works. You can't use normal synchronized threads, since you cant rely on the identity of the bean, and you can't rely on any instance fields that aren't available from accessors. So I ended up creating a stateless bean that stores its state in a static hash map, keyed by a cookie:

import javax.ejb.Remote;
import javax.ejb.Remove;

@Remote
public interface Notify {

String getCookie();

Object getNotification(String cookie);

void notify(String cookie, Object message);

@Remove void remove(String cookie);

}
The server calls getCookie(), passes the cookie back to the client, and then client and server use that cookie to send and receive messages.

I've been programming in Java for years, but the ConcurrentHashMap and LinkedList that I used in this bean are my first experience with generics. Nice.

I've got a version of this that works for me. If you want it, just ask for Notify.java, NotifyBean.java, and NotifyTest.java.

[grmiked]

Thank you very much for your kind response. I would be grateful if you could send by email at

[e-mail]

the respective files you are refering to. I am a beginner with this technology and, they will help me understand the proposed solution better.