1.5.2. Updating CornCo with Enterprise JavaBeans
You may have noticed a flaw in the previous scenario. The checkout servlet sends billing
information to one server and then sends fulfillment information to another server. But it
performs these two actions independently, without any attempt to maintain transactional
integrity and make them behave atomically. In other words, if a network failure or server
crash were to occur after the billing information had been sent, but before the fulfillment
information had been sent, the customer might receive a bill for popcorn that was never
shipped.
The designers of the e-commerce system described in the previous section were aware of
this problem, but since distributed transactions are complex and CornCo does not own a
transaction management server, they simply chose to ignore it. In practice, the number of
customers who would have problems would be small, and it was easier for the original
programmers to let the customer service department sort out any irregularities.
But now, CornCo has hired a new vice president of information systems. She's tough as
nails and likes all her i's dotted and her t's crossed. She won't stand for this sloppy state of
affairs. As her first official act as VP, she buys a high-end J2EE application server and gives
her e-commerce team the job of revamping the online ordering system to use it. The
modified design might work like this:
• The customer interacts with the web server and the shopping cart servlet in the same
way as before.
• The checkout servlet is totally rewritten. Now it is merely a frontend for an Enterprise
JavaBeans component that handles the interactions with the ordering and fulfillment
servers and with the marketing database. The servlet uses JNDI to look up the remote
enterprise bean and then uses RMI to invoke methods on the bean (recall that all
enterprise beans are RMI remote objects).
• The major functionality of the checkout servlet is moved to a new checkout bean. The
bean stores customer data in the marketing database using JDBC, sends billing
information to the billing server using CORBA, looks up a warehouse using JNDI, and
sends shipping information to the warehouse using JMS. The bean doesn't explicitly
coordinate all these activities into a distributed transaction, however. Instead, when
the bean is deployed within the EJB container provided with the J2EE server, the
system administrator configures the EJB component so that the server automatically
wraps a distributed transaction around all of its actions. That is, when the
checkout() method of the bean is called, it always behaves as an atomic operation.
• In order for this automatic distributed transaction management to work, another
change is required in the conversion from checkout servlet to checkout bean. The
checkout servlet managed all its own connections to other enterprise services, but
enterprise beans don't typically do this. Instead, they rely on their server for
connection management. Thus, when the checkout bean wants to connect to the
marketing database or the enterprise messaging system, for example, it asks the EJB
server to establish that connection for it. The server doesn't need to know what the
bean does with the connection, but it does need to manage the connection if it is to
perform transaction management on the connection.
