When using beans with a client application, network connectivity and bottlenecks could become time consuming. A Java Virtual Machine (JVM) usually uses one socket connection, and thus, each bean call would attempt to travel over that same connection. If multiple calls occur before preceding ones are resolved, this could create a bottleneck in your application.

So how do we resolve this? Consider the following snippet of code, which makes three calls to a bean:

remotebean.setFirstName( "Andrea" );

remotebean.setMaidenName( "Jones" );

remotebean.setLastName( "Johnson" );

Each of these calls travels over the socket connection to complete its task. Again, this is not efficient from an application-response standpoint. But suppose these calls were all local? The values would then be set in memory, avoiding this costly network traversal.

The way to accomplish this is to encapsulate the bean properties within an object that is passed back and forth between the server and the client. Using this technique, the client can make the set and get calls entirely locally, eliminating the need for a network traversal/call each time.

Here's an example of a code snippet that would facilitate the encapsulation of the bean properties:

public class RemoteBeanProperties implements java.io.Serializable {

private String firstName;

private String maidenName;

private String lastName;

public void setFirstName(String firstName) {

this.firstName = firstName;

}

public void setMaidenName(String maidenName) {

this.maidenName = maidenName;

}

public void setLastName(String lastName) {

this.lastName = lastName;

}

}

As you can see, the "set" methods for our bean are all made available. This avoids our bottleneck cleanly and efficiently.

In our May 17, 2001 Java TechMail, we looked at a technique to encapsulate a bean's properties within an object and to transfer that object between the client and the server. This reduces the overhead associated with numerous calls to a bean's methods via the network.

The code that would actually pull the object to the client, access the properties, and send the object back to the server could look like:

RemoteBeanProperties p = remotebean.getProperties();

p.setFirstName("Andrea");

p.setMaidenName("Jones");

p.setLastName("Johnson");

remotebean.setProperties(p);

As you can see, we set the same values to the same properties as in the earlier example from our previous TechMail. However, in this example, we call all the methods locally instead of over the network. Under this technique, when the object is sent back to the server, the new values can be applied to the bean's "permanent" properties.

That's all there is to it! This procedure offers a more efficient way to access bean properties, as opposed to numerous network method calls. Also, as the usage of the socket connection is decreased, performance gains could be seen throughout the entire application, as other network-dependant processes encounter decreased contention.

Keep in mind that synchronization issues could arise when using this method. If two processes request the same bean's properties and make conflicting changes, both could be applied incorrectly once the bean is returned. There are a number of ways around this glitch, but the important thing to remember is that there is this potential problem, which may have to be addressed.