Building Java Enterprise Applications

Details, Details, Details

Continuing on with a look at common problems in EJB, it’s time to move to one area that is fairly well understood: the overhead of RMI traffic. More often than not, more time is spent waiting for networks to respond than on actual processing when dealing with EJB. So far, I have spent a lot of time talking about creating a new entity, such as the Forethought office. In that case, very little “back-and-forth” traffic occurs:

Object ref = context.lookup("java:comp/env/ejb/OfficeHome");
OfficeHome home = (OfficeHome)
    PortableRemoteObject.narrow(ref, OfficeHome.class);
Office office = home.create("Dallas", "TX");

In this case, once the home interface of the bean is located, a single call creates the new office. However, when obtaining information about an office, more calls are needed:

String city = office.getCity(  );
String state = office.getState(  );

While these two calls look pretty harmless, each requires a round-trip RMI call. The remote stub has its method invoked, initiates a remote method invocation, waits for a response, and returns that response. All this depends on network latency and all the other costly issues that surround any network transmission. While even this doesn’t seem too bad, take a look at a slightly more complex object:

String sku = product.getSKU(  );
String name = product.getName(  );
String description = product.getDescription(  );
float price = product.getPrice(  );
// etc...

Here, multiple trips over the network are required for these ...