Java Reference
In-Depth Information
populate the fields on our user interface through remote calls to our model.
Such a design can hurt our performance, and it is our first bitter bean.
8.3
Antipattern: Round-tripping
As we populate our bulletin board remotely, we can quickly build up a stag-
gering number of communications. To build a board, we also have to fetch
the discussions in a board; to build a discussion, we have to build all of the
posts in the discussion. This quickly leads to many remote communications
that spin out of control. Indeed, one of the most common EJB antipatterns is
called Round-tripping. Many EJB consultants have made a living going from
customer to customer solving this problem, and preparing the same report
that details causes and solutions. Though there may be many subtle differ-
ences, the causes for the most part are the same. EJB frameworks and environ-
ments make it easy to take an existing model, press a button, and spit out an
EJB -centric object model. This model is then deployed on different hardware
from the base web architecture. As the model is instantiated, the communica-
tion costs explode. Let's take a look at figure 8.4.
InvoiceEJB
CustomerEJB
AddressEJB
+id : int
+date : Date
+customerId : int
+itemid : Collection of int
+id : int
+name : String
+billingAddressId: int
+shippingAddressId: int
+id : int
+street: String
+city : String
0..n
0..n
1..1
1..1
1..1
0..n
InvoiceitemEJB
ProductEJB
+id : int
+name : String
+price : double
+id : int
+quantity : int
+productId : int
0..n
1..1
Figure 8.4 This ER diagram shows an object model for an invoice solution. We create an object
model in a design tool or programming environment, press a button, and generate an EJB model.
This model looks good, but if we deploy it as a distributed solution, it will not perform well.
Search WWH ::




Custom Search