Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

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

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?

Let'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.