Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Client callbacks

What's the best way to broadcast a message from an entity bean to many clients?

By Tony Sintes, JavaWorld.com, 08/18/00

Q I need to have an entity bean to which many clients can connect. When a client sends a message to the bean, the bean should broadcast that message to all of the clients. I tried doing this by having each client send the entity bean an instance of itself (the clients are serializable). At that time the entity bean stores that instance in a vector. When the entity bean gets the message to broadcast, it just calls a method in each of the clients in the vector that prints a string to the command line. This string gets printed in the command line of the server, so obviously this doesn't work the way I want it to. My questions are:

  1. Can this be done using J2EE?
  2. What is happening in the instance that I describe (i.e., why is the message printing on the server)?
  3. Is JMS the solution I am looking for?
To clarify, a simple example of the exact architecture that I described above would be a chat server with a chat client. Clients send messages to the server and the server broadcasts each message to everyone connected to it.

ALet's take a look at question 2 first. I guess the question we need to ask ourselves is: what happens to an object when we serialize it and send it somewhere?

As an example, let's look at Mr. Happy Object in Figure 1.

Figure 1. Mr. Happy Object



Mr. Happy Object is the client from your question. As in your question, Happy is serializable.

The client and entity bean live in different process spaces, as seen in Figure 2.

Figure 2. The client/server environment



These spaces can be on the same machine or on different machines, though it doesn't really matter much. Each space will need to communicate with the other over the network.

In Figure 3 we see that there is something wrong. Happy begins to feel weird. We see that the Serializer (the java.io.ObjectOutputStream, for the humor impaired) is sucking Happy over the network.

Figure 3. The Serializer



The ObjectOutputStream takes an object as input and sends it over its associated java.io.OutputStream. The stream achieves this feat by utilizing the object's writeObject() method. This method knows how to write the object out to the stream.

We see in Figure 4 that after being sent down the stream, Happy is reconstituted on the other side by the Unserializer. (Again, we all know the Unserializer as the java.io.ObjectInputStream.)

Figure 4. The Unserializer



The ObjectInputStream achieves this feat by calling the object's readObject() method. This method knows how to read itself from the stream.

However, you'll note that there are now two Mr. Happy Objects and that the entity bean only has reference to the Happy that was transported to its environment. This isn't Star Trek, so when we beam an object from one environment to another, we don't move the original object. Instead, the process is much closer to cloning (in fact, you can write a very slow object cloner using serialization). Be aware that transient information is lost during serialization.

So, when your entity bean makes a call on Happy, it isn't the Happy that you think it is. Instead, it is a copy of the original client.

1 | 2 |  Next >
Resources