Bitter beans - Bitter Java - page 227

fields on the invoice. The total cost is 10*4 N . That does not seem too bad,
but let's look at some real-world numbers.
If we assume 50 milliseconds per network transaction, this is the cost of
fetching a single invoice:
For 1 invoice with 2 items
18 × 50 mSec = 900 mSec—almost an entire second
For 1 invoice with 20 items
90 × 50 mSec = 4500 mSec—4.5 seconds

These times are relatively slow, but reasonable. However, it's probably unreal-
istic to expect our users to fetch a single invoice. In reality, they'll probably
usually fetch several and drill down to the one they're seeking. The math for
multiple invoices is grim:
For 10 invoices with 2 items
9000 mSec—9 seconds
For 10 invoices with 20 items
45 seconds!
For 100 invoices with 20 items
450 seconds, or 7.5 minutes

We aren't fetching too many bytes in any single instance; we're simply taking
too many round-trips. Some might quibble with our assumptions, but if we
allow users to fetch more than a single invoice at a time, this architecture
won't hold up to even the most basic performance requirements. We have the
same problem with our bulletin board example. Boards contain discussions
that contain posts. We simply have to refactor.

8.3.2 Chatty interfaces

The UML sequence diagram is the perfect tool for identifying round-tripping.
Figure 8.5 shows the sequence diagram for the Invoice example. We've com-
bined the local EJB and its home for simplicity. In this case, we're looking at
the interface between the EJB s and the view, since each of those method calls
will be expensive distributed invocations. First, the controller issues a find to
the invoice home, which triggers cascading finds on other EJB s. Next, we
include get methods to populate our user interface. Let's assume that we're
building a data bean in our controller that we'll pass to our JSP . Because we
have accessor methods for all of the attributes that will fill the interface, we