The life-cycle management of entity beans in this additional layer can be expensive. Activation is
equivalent to at least a single database/disk-read operation, and passivation is a database/disk-write
Additional beans participate in the transaction.
Of course, it is up to the application architect to decide if the benefits of entity beans outweigh the likely
loss in system throughput.
DISTRIBUTION AND SCALING ISSUES
With the popularity of Web-enabled enterprise systems, businesses are finding their back-end systems
unable to cope with the volume of incoming Internet traffic. There are two ways of increasing the
processing power in the server tier:
Scaling up, or "vertical" scaling, refers to the addition of computational and system resources—for
example, adding memory to a single machine. This form of scaling relies on the application server
having no inherent bottlenecks in its internal architecture. If this is the case, given more system
resources and processor power, the application server software should be able to fully utilize the
additional resources and increase system throughput as a result.
Scaling out, or "horizontal" scaling, means that, instead of replacing an existing machine with a more
powerful model, the server application is distributed across more than one machine. This should
increase overall system resources and processing power by making additional machines available to
Scaling out is usually regarded as more difficult to implement than scaling up, because it requires more
complex configuration and system management. The application server must also provide load-balancing
mechanisms to make sure that the additional resources on different machines are fully utilized by clients.
Nevertheless, a system that runs on multiple machines does provide some benefits over one running a
single large machine:
If one machine fails, there are others that can take over the work. Machines
might fail because of power or network outages, operating system crashes, application server
failures, or even bugs in the application code itself.
A network of smaller machines may have a better price/ performance ratio than a
single large machine has.
Many application products provide clustering services to enable the scaling out of applications. Again,
though, clustering products vary considerably, and architects need to explore these differences carefully.
Many EJB servers can coordinate transactions that involve multiple objects residing in various processes
in a distributed system. Distributed transaction processing using the two-phase commit protocol is often
essential in building enterprise-wide systems.
An architect designing an EJB system needs to consider carefully whether distributed transactions are
necessary. This is because of the overhead involved in managing them, which increases as the number
of transaction participants increases. If there is no need to coordinate the transaction across multiple
resource managers (or databases), there is no need for the two-phase commit protocol.
Further, the transaction coordination and commit processes may involve several remote calls that pass
over the network. These may be between the EJB server or container and an external transaction
management process. If the distributed transaction implementation provided by the EJB server incurs
additional remote calls in coordinating transactions, using distributed transactions can slow down an EJB
system considerably, inhibiting overall system scalability.
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
395 / 463